Section: New Results

Model-Driven Engineering and Video-surveillance

Participants : Sabine Moisan, Jean Paul Rigault, Sagar Sen, François Brémond.

In the framework of our research on model engineering techniques for video-surveillance systems, we have focused this year on the runtime adaptation of such systems.

Video-surveillance systems are complex and exhibit high degrees of variability along several dimensions. At the specification level, the number of possible applications and type of scenarios is large. On the software architecture side, the number of components, their variations due to possible choices among different algorithms, the number of tunable parameters... make the processing chain configuration rather challenging. Moreover, the context of an application may change in real time, requiring dynamic reconfiguration of the chain. This huge variability raises problems at design time (finding the configurations needed by the chain, foreseeing the different possible contexts), at deployment time (selecting the initial configuration), and at run time (switching configurations to react to context changes).

The first step was to formalize in an unified way all the necessary concerns —at the specification as well as at the component level— and their relations. To this end, we rely on Feature Models and (semi) automatic model transformations (Here the “features” correspond to selectable concepts of the systems; they can be at any abstraction level (a feature may correspond to an specification entity such as “Intrusion detection” or to a more concrete element such as “High frame rate”). The features are organized along a tree, with logical selection relations (optional, mandatory features, exclusive choices...) and some constraints that restrict the valid combinations of features (i.e., configurations)). Feature Models are widely used to represent systems with many possible variation points. Moreover they are liable to formal analysis (using propositional logic and satisfiability techniques) and thus lead to valid configurations, by construction. We have developed two feature models, one for the specification of the application (type of application, context of execution, expected quality of service,etc.) and one for the implementation representation (components and their assembly). Each model has its own internal constraints. Moreover, the two models are not independent: they are connected by cross model transformation rules that formalize the bridge between application requirements and component assemblies that realize them [40] .

Second, we propose a framework to derive valid possible system configurations and to adapt running configurations to context changes. Users can select features describing their application in the specification model, through a simple graphic interface. The outcome is a sub-model of the specification model. Based on the cross model transformation rules, our framework automatically transforms this sub-model into a sub-model of the component model. The latter represents all possible component configurations of the target video-surveillance system that satisfy the specifications. Both sub-models will be kept throughout the system life. They are used while the system is running to adjust its configuration in response to context changes.

To achieve this dynamic adaptation, our framework sets up three collaborating modules as shown in Figure 25 :

Figure 25. Run Time Adaptation Architecture

• the Run Time Component Manager (RTCM) captures low level events manifesting context changes (e.g., lighting changes); it forwards them to the Configuration Adapter which returns a new component configuration; the RTCM is then responsible for applying this configuration, that is to tune, add, remove, or replace components, and possibly to change the workflow itself.

• the Configuration Adapter (CA) receives change events from the RTCM, translates them into the feature formalism, and forwards the result to the Model Manager; in return, it obtains a sub-model of component configurations compatible with the change; this sub-model is a compact representation of a set of valid configurations and the CA is responsible to select one and to instruct the RTCM to apply it; this selection uses some heuristics, possibly based on a cost function such as minimizing the number of component changes in the processing chain or maximizing the quality of service (e.g., accuracy, responsiveness).

• the Model Manager (MM) manages the representation of the two specialized Feature Models corresponding to the specification and possible component assemblies of the current application together with their constraints; its role is to enforce configuration validity. It is also responsible of the set of rules relating run time events and (de)selection of features in both models. From the CA, the Model Manager receives information about incoming events; it uses the rules to select or deselect the corresponding features; it then applies constraints, rules, and model transformations to infer a component sub-model that represents a subset of valid component configurations and that it returns to the CA.

This year, we have tested our approach on simple applications using well-known libraries (OpenCV) on different scenarios. At the moment, 77 features and ${10}^8$ configurations are present in the specification model while 51 features and ${10}^6$ configurations are present in the component model. Once the video surveillance designer has selected the features required by an application, before deployment, the average number of features to consider at runtime in the component model is less than ${10}^4$. The configuration spaces is reduced by several orders of magnitude and enables the use of the other tools in the end-to-end engineering process, whereas it would not have been possible without. Our experiments show the feasibility of such an approach with a limited performance overhead (if any) compared to traditional run time control where ad hoc adaptation code is hardwired and does not rely on the run time availability of an abstract representation of the application and its context evolution [29] . The next step will be to test our approach on our SUP platform and to study intelligent configuration selection heuristics.